Q: I'm erasing my windows with a color other than white,
by setting the window's background color and calling EraseRect. But in cases
where the Window Manager gets there first (window ordering changes or a window's size gets larger)
I still get flicker, because the Window Manager erases with the wContent color from the window's color
table (white by default) and not the port's background color. Is there a friendly, clean way to avoid
that flicker? (I notice that in System 7.5, background colors are implemented with EraseRect, just as I'm
doing it. Are you simply assuming the flash will be minimal?)
A: One of the Window Manager's functions is to ensure that the
content region of a window is opaque when it needs to be: that's why the Window Manager
"pre-erases" the window when the content region grows, before your application
gets a chance to. As you point out, if your application is then erasing large
areas of the window to a different color, you'll get a noticeable flicker in
those parts of the content region that needed to be opaque. This is an
unfortunate side effect of a necessary maneuver by the Window Manager. Any
system dialogs that set a background color and use EraseRect will suffer from
the same flicker (although you won't spot it so often, since for the most part
they're modal, nonresizable, and relatively small).
There are two solutions: If you create your windows from 'WIND' resources, you
can create 'wctb' resources with the same ID and an appropriate wContent color
and they'll automatically be used when the window is created. Alternatively,
you can use the SetWinColor routine to apply a color table to a window after it
has been created.
|
